The invention relates generally to debugging visual programs, and more specifically relates to a system and method for debugging visual paradigms and embedded visual or source programs.
Visual programming environments, or paradigms, such as that provided by IBM® WEBSPHERE® BUSINESS INTEGRATOR, are becoming commonplace for creating computer programs (IBM and WebSphere are registered trademarks of International Business Machines in the US, other countries, or both). Instead of writing lines of code, programmers create programs by linking together transforms that provide predetermined functions (e.g., mapping, business rules, etc.). Transforms are typically represented by boxes in the programming environment that can be linked together with arrows that dictate the flow of the program.
In some instances, the visual paradigm does not include a runtime engine, but instead generates some type of intermediate code, such as JAVA™ source code, which can then be compiled and run by an interpreter, such as a Java virtual machine (JVM). (Java and all Java-based trademarks are trademarks of Sun Microsystems, Inc. in the United States, other countries, or both.) One of the challenges in designing programs using such visual paradigms involves debugging the program. A debugger tool should allow the programmer to step through the visual paradigm to track the behavior of the program. However, because these types of visual paradigms are first translated, e.g., into Java, there is no link back to the visual paradigm when the program is executed, thus making it difficult to implement a debugger tool.
Another area in which a similar challenge exists involves debugging embedded programs. There are situations where one tool uses another tool to generate code to be embedded in another context. For example, Java code might be embedded in an intermediate form to be input into a subsequent code-generation. As well, in modern development tools, it is often desirable to give users a high level programming paradigm to work with instead of a procedural or object oriented language. For instance, Java Server Pages (JSPs) represent a high-level source code format for generating Java servlets. Often, a visual paradigm is preferred instead. For instance, in the WebSphere Integration Developer, the BPEL (Business Execution Processing Language) editor, the Map editor, and others, can use the Activity Editor to allow the user to visually construct code that is then translated to Java. The Activity Editor is thus an example of an “embedded editor” in which one editor is used within the context of another. The code produced from such an editor is then embedded within the code produced from the parent editor.
A problem that arises revolves around how to debug such embedded code in the code's original context, whether it is JSP, visual expressions, etc. Specifically, the debugging should occur in the context of the parent editor that was driving the creation of the embedded code.
When the tool that creates the embedded program is asked to save the program to disk, the program, e.g., the Java program, is typically provided to the parent editor as a block of code that can be incorporated as character data in the persisted form. For example, FIG. 5 depicts a visual expression constructed with an Activity Editor. Having allowed the user to visually draw this expression, the Activity Editor would then generate Java code that that would take three arguments, A, B and C, and would produce a Java expression that multiplies A and B, subtracts C from that, and calculates the square root to produce a result. The generated Java might be embedded in an XML document which would serve as a kind of “intermediate form” for input to a code generator. Assuming the visual expression shown in FIG. 5 was used while creating a data map, the resulting XML might, for example, look like the following:
</propertyMap> <propertyMap executionOrder=“2”>  <join delimiter=“ @” prefix=“!”>   <input businessObjectVariableRef=“ApplicationAddress”property=“addressLine1” />   <input businessObjectVariableRef=“ApplicationAddress”property=“addressLine2”/>   <output businessObjectVariableRef=“GenericAddress”property=“streetAddress”/>  </join> </propertyMap> <propertyMap executionOrder=“3”>  <split delimiter=“-”>   <input businessObjectVariableRef=“ApplicationAddress”property=“phoneNumber”/>   <output businessObjectVariableRef=“GenericAddress”property=“areaCode”/>  </split> </propertyMap> ... <propertyMap executionOrder=“6”>  <customAssignment>   <output businessObjectVariableRef=“GenericAddress”property=“isBillingAddress”/>   <javaCode>    int temp1 = 3 + 5;    int temp2 = temp1 + 10;    return Java.lang.math.sqrt(temp2);   </javaCode>  </customAssignment> </propertyMap></businessObjectMap>
In the case of the above map, the XML code will itself be used by a code generator to generate Java code. The Java code that lies between the tags <javaCode> and </javaCode> would be placed within that generated Java code. If one were debugging the Java that resulted from the map code generation, one would encounter the Java code from the Activity Editor embedded within it. However, it is not desirable for the user to be debugging generated Java. Instead, the user should debug in the form in which the code was written or composed.